This project shows how the scrolling routines can be used even if you don't want to use the tiling routines. For instance, if you need to make a game that has a large picture in the background instead of tiles, you could create a SpriteWorld where the background and work areas are large enough to hold the picture, and then simply scroll around in that offscreen area. Of course, tiling is usually better, since creating an offscreen area as large as the picture could take up a lot of memory, and also limit the size of your scrolling area, since too large of an area would require too much memory.
To scroll the area, simply click inside the window and drag around. This is probably the fastest real-time dragable scrolling you'll ever see! Also, try moving the window itself around - you can now do this and still draw directly to the screen, thanks to SWWindowMoved! To quit the demo, click on the close box of the window.
Cursor Magic
One really neat thing this program demonstrates is how to keep the cursor from flickering while it's in front of a scrolling animation. Normally, the mouse cursor would flicker if you used CopyBits as your ScreenDrawProc because CopyBits hides the cursor whenever it moves in front of the area its drawing, and shows it again once it's done drawing. And if you use BlitPixie as your ScreenDrawProc, the mouse won't be hidden, but if it is in the way, BlitPixie will draw right on top of it, completely erasing it until it is moved again. This causes the mouse to completely disappear if it is left in front of the scrolling area.
The solution is to create a "mouse sprite" that looks just like the mouse, but is actually a Sprite that is moved each frame to the mouse's current location. Thus when the screen is updated and the real cursor is erased, the "fake" cursor shows up right where the real cursor had been, and the user never realizes that the real cursor was erased.
This is a minor problem with the this technique, and that is that the real cursor often moves faster than the fake sprite cursor, resulting in double images of the mouse. The slower the frame rate of your animation, the more obvious this becomes. One solution to this would be to hide the real cursor whenever it enters the boundaries of the window by using ShieldCursor. This eliminates the double mouse images, but makes the mouse sluggish (since the fake mouse only moves as fast as the animation rate). In my opinion, the "double image" problem is barely noticeable, and having a faster moving mouse is much more important than having a sluggish mouse without the double-image effect. However, if you want to try the ShieldCursor option, simply set the kShieldCursor flag at the beginning of Large Background.c to true.
Also, if you want to see what the animation looks like without the fake mouse cursor, set kCreateMouseSprite to false. This will make the mouse disappear or flicker whenever it is moved in front of the window since it will be erased each time the screen gets redrawn. In addition, you can set kUseCopyBits to true to see what it looks like when CopyBits is used. On the one hand, this makes it easier to see the double mouse images, but on the other hand, it eliminates the temporary "mouse droppings" that occur when the mouse moves in front of a sprite when BlitPixie is used.
WindowShade
The demo behaves properly even when WindowShade is used. To see if a window is "rolled up" with WindowShade, only simply needs to check the window's visible region:
// If window "rolled up" with WindowShade...
if ( EmptyRgn( gWindowP->visRgn ) )
StopDrawingStuff();
Obviously, it doesn't look right for SpriteWorld to keep drawing the animation when a window is rolled up, which could happen if you are drawing directly to the screen and don't specifically check to make sure the window isn't rolled up before animating each frame.
